他離開的時候，這個專案的需求只有一句話；他回來的時候，專案已經不需要他也跑得動。中間隔著的，就是這整個系列。

上線滿月，大神歸隊

退款功能上線，滿一個月了。

數字不驚人，但誠實：七成的退款申請，從三個工作天變成幾分鐘內有結果；月底對帳，財務第一次沒有追到任何人的座位旁邊；期間金流失敗過幾筆，畫面誠實轉成「失敗」，客服照著指引處理，沒有驚動任何工程師；重送的通知也來過，防護後面，同一筆訂單只退了一次。

然後，資深工程師歸隊了。另一個專案的火救完，他回到這個團隊——離開的時候，這裡的需求還只有一句「幫我加一個線上退款功能」。

照過去的慣例，歸隊第一件事是找人補課：拉著 PM 跟幾個工程師，把幾個月的來龍去脈用人肉轉述一遍。這次沒有。他自己讀：看板上的 Goal／Non-goal 卡、MVP 切割記錄、牆上勾滿的五條 AC、幾份 ADR、部署 Runbook——在「今天是不是財務鎖帳日」那一行，他停了一下，笑了——最後是 Retro 留下的隱性知識落地記錄。

一個上午，沒有問任何人任何事。中午他放下最後一頁，說：

「你們自己就跑起來了。」

下午，PM 給了他一個新題目：評估第二條金流通路。多通路是 Day 24 白紙黑字的 Non-goal，MVP 切割記錄的最後一欄寫著「不做的什麼時候回來看」——現在就是回來看的時候。新通路沒有人串過、文件跟現實有落差、對帳規則跟現有的完全不同，連該先問哪些問題都還不知道。

他看著那份評估需求，眼睛亮了。

三十天前，我們會怎麼用他

如果是三十天前，這一幕會完全不同。

歸隊的大神會被立刻放回原本的位置：需求不清的單子先給他看過、跨組的介面請他去喬、驗收前請他把功能再修一輪、新人的問題都指向他、每場客戶會議最好都有他在——以防有人問出沒人答得出來的問題。

每句單獨看都有道理：資深的看得最快、有他把關最保險、他最知道客戶要什麼。合在一起，就是第二部整整七天的景象：組織把最強的人，用來每天填同一批洞。

注意那些洞的共同點：答案其實都已經存在。需求該問的十件事、介面的欄位語意、驗收那天客戶會點哪裡、當初為什麼這樣設計——這些不是待解的難題，是已解的答案，只是存放位置在他腦裡。他每天做的不是解題，是把腦中的答案，再抄一遍給流程。

用天才做抄寫員，帳面上是賺到——不用寫文件、不用開對齊會議，多有效率。實際是雙重浪費：答案被抄一百次也不會落地，而被抄寫佔滿的頻寬，本來可以拿去解真正沒有答案的問題。

新金流通路評估，就是真正沒有答案的問題：沒有前例可查、沒有 Runbook 可翻、判斷錯了賠的是真的錢。這種題目 Checklist 接不了手，AC 也寫不出來——AC 只能寫已經知道的事。這才是高手該在的位置。

高手的價值，是處理真正困難的新問題，不是每天替流程補同一個洞。

還有一件事跟三十天前不一樣。他這次評估所做的每個判斷——為什麼選這家、代價是什麼、什麼情況該翻案——會照著 Day 29 的節奏落地成 ADR 與紀錄。成熟的流程不是不需要高手，是讓高手產出的答案有地方降落，而不是永遠住在他腦裡，等下一次「還好有他在」。

回到 Day 01 的那兩個問題

Day 01 的會議室裡，客戶窗口問了兩個問題，然後全場安靜，所有視線移向角落的那個人。

「所以這一版交付的時候，我會拿到哪些功能？」

「你們怎麼判斷這些功能算是做完了？」

三十天後，把同樣的兩個問題丟進這個團隊：

會拿到哪些功能？
→ Goal／Non-goal 卡：這一輪承諾解決什麼問題、明說不做什麼
→ MVP 切割記錄：邊界在哪、不做的什麼時候回來看
→ 回答的人：任何一個站在看板前面的人

怎樣算做完？
→ 五條 AC：每一條可檢查，連失敗與重送都有判準
→ 完成語意定義表：受理、入帳、對帳，每一層由誰確認
→ 回答的人：任何一個讀得到牆的人

兩個問題還是要有人回答——差別是，答案的存放位置從「某個人的腦袋」搬到了「所有人都拿得到的地方」。回答的人可以是任何人，包括上工第二週的新人。

Day 01 的自我檢查表，第五題是這樣寫的：「最資深的那個人下週請假，上面四題的答案不變。」這個團隊給出的版本比題目狠：他不是請假一週，是缺席了整個第三部與第四部——翻車的時候不在，重做的時候也不在。答案照樣長出來了，而且不在任何人的腦袋裡。

這 30 天，收成三句話

瀑布提醒我：承諾以前，先知道自己答應了什麼。

這是第一部：承諾之前先談判、先找對說了算的人、先知道用什麼交換——答應了卻說不出答應什麼，連瀑布都沒做好。

敏捷提醒我：不要假裝自己一開始就知道所有答案。

這是第三部繳的學費，也是第四部的起點：一句話需求人人都以為自己懂，隱藏規則要用問的，不要用炸的；答案會逐步浮現，所以節奏與回饋比全盤計畫誠實。

工程治理提醒我：不要讓答案永遠只存在某個人的腦袋。

這是第二部的病與第四部的藥：血脈壓制不是能力問題，是知識存放位置的問題。Artifact 可以輕到只有四行，但 Requirement、Decision、Verification、Acceptance、Change 這些責任，不能只活在人腦。

這次到底誰在吸收代價？

最後一次，老規矩。

Scope       □   承諾什麼、不做什麼，寫在卡上；要改，走排序
Time        □   節奏固定兩週，沒有人的行事曆被炸開
Cost        □   沒有追加，也沒有隱形加班在補貼
Quality     □   AC 站哨、測試守夜，沒有「先上再補」
Risk        □   每件事至少兩個地方知道：一個是人，一個不是
人          □   ← 系列唯一一次，六格全空

六格全空，不代表不確定性消失了。金流照樣會失敗、規則照樣會被發現、使用者照樣會問出沒人想過的問題——差別是，這些不確定性由機制吸收：Goal 吸收（目標句擋掉順便）、Scope 吸收（重新排序，不是插單）、Feedback 吸收（在還便宜的時候現形）、Artifact 吸收（答案落地，不用人記）。

前三部，「人」那格勾到麻痺。不是那些團隊的人比較弱，是整個系統裡只剩人這一格有彈性。第四部做的所有事，一句話：把彈性裝回其他五格，讓人可以下班、可以請假、可以去解值得他解的問題。

今日 Artifact｜30 天輕量工程工具箱索引

三十天，三十件小東西。單獨看，每一件都小得不好意思叫方法論；合在一起，是一套不靠大神也跑得動的最小工程配備：

Day 01｜假敏捷自我檢查表
Day 02｜最小承諾記錄
Day 03｜最小回饋記錄
Day 04｜「先固定什麼」對照卡
Day 05｜最小變更報價單
Day 06｜Stakeholder Map 最小版
Day 07｜承諾前談判記錄
Day 08｜一句話需求最小澄清清單
Day 09｜最小介面契約
Day 10｜AC 最小範本
Day 11｜最小 ADR
Day 12｜最小 Change Record
Day 13｜Onboarding 缺口清單
Day 14｜大神依賴盤點表
Day 15｜開工前五問
Day 16｜Definition of Ready 最小版
Day 17｜介面與責任對照表
Day 18｜完成語意定義表
Day 19｜變更／發現判別卡
Day 20｜敏捷誤解對照卡
Day 21｜工程責任底線清單
Day 22｜Decision Authority 卡
Day 23｜Goal／Non-goal 卡
Day 24｜MVP 切割記錄
Day 25｜Conversation 檢查單
Day 26｜退款 AC 實例
Day 27｜切片計畫
Day 28｜Feedback Record
Day 29｜隱性知識落地記錄
Day 30｜本索引

用法跟這個系列來的時候一樣：不要一次導入三十件。找到你最痛的那一格，索引裡有對應的一件，小到明天站會之後就能開始。

今日一句

一套好的開發方法，不應該只能在最強的人都在場時才能運作。

這個系列沒有明天可以預告了，所以改成一個邀請：回到 Day 01，那份假敏捷自我檢查表還在。三十天前勾不滿的人，現在再勾一次——不是為了勾滿，是為了看清楚每一格空白對應哪件小東西，然後從那一件開始。

大神請假的那一天遲早會來。希望到時候，你的團隊安靜幾秒之後，視線移向的不是某個角落的人，而是牆上。

三十天，感謝收看。